Large enterprises throughout the world rely on mainframe computers running sophisticated Database Management Systems and applications to mange data critical to the survival and growth of their business. One such Database Management System is IMS. IMS is a Hierarchical Database Management System (HDBMS) developed by International Business Machines Corporation. IMS has wide spread usage in many large enterprises where high transaction volume, reliability, availability and scalability are of the utmost importance. IMS, therefore, is particularly relevant to the teachings contained herein wherein analysis pertaining to efficient operation (e.g. problem diagnosis, capacity planning, trend analysis, etc.) is of the utmost importance. Frequently, the system log is an important resource in performing this analysis.
Multiple types of system logs are found within database systems. For example, an IMS system uses the OLDS (Online Log Data Sets) log, and its archival copy SLDS (System Log Data Sets). The OLDS log is the primary receiver of system-generated records that capture important data processing event-related information during IMS processing. Logs, and the information contained therein, are primarily generated and used to maintain IMS system integrity. However, users of IMS have often found many other uses for this information. Typical examples include monitoring, tracing, creating audit trails, debugging, capacity planning and trend analysis. These activities, or tasks, require log records related to the task to be grouped together in order to formulate a “story” describing the various activities.
System utility programs, such as IBM's DFSERA10 utility program, have been traditionally used to access and format log records for the various uses contemplated by the user. However, even though the needed data may be retrieved by this utility, a serious shortcoming exists in that the user must know what records to search for in order to obtain the desired results for the particular task at hand. Furthermore, the user would also need to know how to relate the various records in order to create a meaningful and coherent history. Because the system log records are designed primarily for system use, and not for secondary user tasks, the user is greatly disadvantaged in obtaining and organizing task related data from the system log.
Each log record is identified by a one-byte hex field known as a “type code”. A log record may also optionally contain an additional one-byte “subtype code”. In order to properly interpret and provide meaning for a given log record, a DSECT (Dummy Section) matching the type code and subtype code for the given record must be utilized. The large number type codes and subtype codes, in combination with large log file sizes and large record sizes, results in an extraordinarily tedious process in attempting to perform most user tasks involving an analysis of log records.
For example, IMS creates and maintains the following types of log records relating to functions within the IMS sub-system:                Data Com/Transaction Mgmt: 01 02 03 11 12 16 31 33 34 35 36 63 72        Full Function Database Processing: 20 21 27 29 4C 50        Fast Path Database Processing: 40 59        System Processing: 01 03 07 08 35 33 36 37 40 56        Queue Management: 01 03 07 08 31 33 34 35 36 27 40        DBRC: 49        Online Reorg: 29        
System exits to DFSERA10, such and IBM's DFSERA70 system exit, are available to assist the user in searching for log records matching a particular search element. Typical search arguments, for example, include PST (Partition Specification Table), System ID, Recovery Token, PSB Name and DBD Name. However, even with this added flexibility provided through the DFSERA10 system exit, it is unlikely that a user will know all needed search elements. Furthermore, numerous log records may be related to a particular specified search argument, but not all of these contain the actual search element within the record and accordingly may be missed by the user altogether with information particularly relevant to the task at hand.
Accordingly, there is a great need to provide assistance to system administrators and other support personnel in the retrieval of task related log records whereby all relevant information to the particular task at hand is efficiently returned without requiring detailed internal knowledge of hundreds of different log record types, their information content, and their interrelationships.